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18 1 INTRODUCTION 

oars This Quarterly Technical Report is the current edition in a 

’ series of reports which describe the work being performed at BBN 

P= a in fulfillment of several ARPA work statements. This QTR covers 
+. 
f », work on several ARPA-sponsored projects including (1) development 
Gy a 
( of the Pluribus Satellite IMP; and (2) development of the Mobile 
. is Access Terminal Network. This work is described in this single 
rs Quarterly Technical Report with the permission of the Defense 
. a Advance Research Projects Agency. Some of this work isa 
~ oy continuation of efforts previously reported on under. contracts 
Ne oé 
Ma DAHC15-69-C=-0179, F08606-73-C~0027, F08606-75-C-0032, MDAI03-76- 
( pg C-0214, MDA903=-76-C-0252, NO00039-79-C-0386, and N00039-78-C-0405, 
ve and N00039-81-C-0408. 
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cal 2 PLURIBUS SATELLITE IMP DEVELOPMENT — 
o. a 
ot 

bs This Quarterly Technical Report discusses recent progress in “s 
it the development and systems integration of the Wideband Network. 

2 It covers systems integration work done at several Wideband A 
o 

we Network task force meetings, improvements made to the PSAT o 
=— software, and progress made in the development of the BSAT. This - 

{ 

on QTR includes a detailed discussion of the design of the PSAT = 

{ 7. b> 

on translator program which will be used to connect the _ BSAT, 

Poe ~ 
. running in Voice Funnel hardware, up to an ESI and earth terminal a 
= 

ee for test and debugging purposes. fa 
oe 1) 
a 

( : ae 

be 2.1 Wideband Network Systems Integration Activities 

=) < 
° “ 
“ The Wideband Network task force convened for network 

— debugging sessions several times during the quarter. During the . 
oe week of November 14, they met at Lincoln Laboratory to “work on ie 

wa problems associated with three site network operations. 7 
a Multisite operation uncovered an ESI problem which disrupted the me 
vn ae 
"e es 
ee network when several consecutive long outoing messages were 

Poe “. 
oe transmitted by the PSAT to the ESI. The problem was corrected by a 
e 

Soe increasing the ESIt‘s internal uplink delay from 3 to 6 ~ 
‘ + 
w, a 
af milliseconds. “ 
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a Y Linkabit finished debugging the ESI=-A at ISI during the 

x : month of November. By the end of the month the ESI-A had been 

x . operating stably on the network for many days. In the course of 

C v. working with Linkabit to debug the ESI-A, a near-end crosstalk j 

ce . problem was discovered with the PSAT Satellite Modem Interface : 

Ss (SMI). This problem was corrected by replacing the internal 
SMI-to=-PSAT Fantail flat ribbon cable by a cable made up of 

= 2 twisted pairs. 

a : During December, an additional site was added to the 

= network, BBN, Lincoln Laboratory, and Linkabit visited Ft. 

= Monmouth on December 5-7, installed an ESI, and successfully : 

= r brought the site up on the air. A PSAT software bug was , 

oe identified which disrupted normal network operation when the Ft. 

ss . Monmouth site was not the leader on the satellite channel. 


Le Significant progress was made in Wideband Network systems 


ove il 


» 


integration during January. On January 9, BBN found and 


< 
Pn 
? 

waft 


ot 

Nr ie corrected the PSAT software bug which prevented Ft. Monmouth from 

eo ts operating on the channel unless it was leader. A site-dependent 3 
ce," ° 
ree : pointer was accessing a table incorrectly. Correcting this bug 1 
Hes . allowed Lincoln to conduct extensive speech testing between Ft. 

e e 

ae Monmouth and Lincoln using their Packet-to-Circuit Interfaces 

tt (PCI) at both sites. 
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¢ 2.2 Wideband Network Operations and Maintenance a | 
“s Several PSAT hardware problems were encountered during the 

Ns quarter, The hardware problems encountered with the ISI PSAT 

oe during November, a failed power supply, a non-functioning i 
a processor, and a faulty backplane, were repaired on December 4. 

is Additional hardware problems were encountered with the ISI PSAT 

2. on December 18. The problems were finally traced to a set of oo 
"e faulty bus couplers which were replaced on December 28. A host es 
= port in the RADC PSAT, which had failed at the end of November, zs 
- was replaced on December 1. On December 5 the RADC earth ms 

terminal high power amplifier (HPA) went uve standby mode. This as 

r condition was not cleared by Western Union until December 12. ae 
m The SRI PSAT experienced hardware problems during December. 
a Although significant effort was expended during the month trying = 
gh to track down the cause of the problems, progress was slow, and ms 
BS the problems remained unresolved at the end of the month. The ee 
a <- 
a hardware problems were finally traced to a set of bad bus “- 
* couplers and memory boards in early January and the PSAT was ae 
m returned to operational status on January 8. An ESI was 
on installed at SRI on January 13; however, a problem was discovered = 
is with the High Speed Packet Modem (HSPM). Representatives from 

= BBN, Lincoln, ISI, and Linkabit visited SRI on January 19-20 and 

* replaced the HSPM with the Burst Test Modem (BTM). When the site 

3 was brought up on the channel, problems were encountered with the 
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on ; 

{r | earth terminal's high power amplifier (HPA). It was found to be 
"f operating at a very low output power level. The channel bit error 
Pee Pa) 

oe = rate (BER) was measured at 1x10##-3, During the visit, ISI 
Jam] repaired the Switched Telephone Network Interface (STNI) which 
ao they had installed in a Packet Voice Terminal (PVT) at SRI, and, 
‘i with rate 1/2 coding, it was possible to make a telephone call of 

acceptable quality over the channel in spite of the high bit 

mae ey 

a 

pete “i error rate. At the end of the quarter, Linkabit was still 

an “! working on repairing the modem, and Western Union was working on 
ss 

el the earth terminal. 

ae 

ae 

~~ 


oO 
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2.3 BSAT Software Development 


e Cy 


* BSAT software development during the quarter focused on the 


‘ alae 
CAC ie 
bh he ae a er 


L coding and debugging of the software-based satellite channel 


f 
*, *, Ww % 


a Simulator (described in a previous QTR), on the debugging of the 


oa ae 


re 


" “ datagram scheduling code, on the coding of routines to handle 
Ps stream setups and to manipulate the stream databases, and on the 
a - design of the PSAT Translator program. An overview of the PSAT 
oS oe translator is given in the next section. 
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es 

a 
2.4 Design of the PSAT Translator Program 4 


Currently the PSAT is connected to the ESI and earth 
terminal equipment via a Satellite Modem Interface (SMI). The 
SMI provides a satellite channel clock to precisely time the 
transmission and reception of channel bursts. It also contains 


logic to generate and check 32 bit CRCs for error detection. The 


& PSAT SMI exchanges data with the ESI using a count-based variant = 
on of the Arpanet VDH=-style protocol. For the BSAT, BBN has proposed ; 
* to develop a new HDLC based interface, the Butterfly Satellite S 
Modem Interface (BSMI) to communicate with a new ESI-B currently oe 
- being developed by Linkabit. The precise timing functions will es 
a be moved to the ESI-B. However, the CRC error checking will % 
iz still be performed by BSAT. . 
. Ly 
: To allow testing of the BSAT software before either’ the ° 
we ESI-B or BSMI are available, BBN has proposed to develop a 3 
a Pluribus program for the PSAT known as the PSAT Translator. The . 
aie PSAT Translator will allow the BSAT running in Voice Funnel ‘ 
a hardware, currently at several Wideband Network sites, to be a 
a connected to the current ESIs and ESI-As, using the PSAT's SMI. : 
BS Figure 1 shows the configuration in which the PSAT translator Z 
ae will be used. 
a In the PSAT, transmission of scheduled bursts is performed * 
ae by the Satellite Modem Interface (SMI). The SMI transmits a + 
ee : 
@: rc 
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burst to the ESI-A upon timeout of a time-to-go stamp on the 
pending burst. The time reference for the SMI is based on a clock 
Signal provided by the ESI-A. When the ESI-B is developed, it 
will perform this timeout function. The PSAT Translator accepts 
scheduled bursts from the BSAT and performs the format and time 
conversions necessary for proper time out and transmission to the 
ESI-A. For traffic received from the satellite channel, the PSAT 
Translator also performs the proper format and time conversions 
for transmission to the BSAT. The PSAT Translator combines with 
the current ESI or ESI-A to simulate the function which the ESI-B 


will have. 


2.4.1 PSAT Translthe PSAT Translator is taken 

largely from the Host Protocol Module (HPM) of the PSAT. In the 
PSAT HPM, input and output are accomplished by the MsgIn and 
MsgOut device drivers, MsgIn and MsgOut perform I/0 driver 
functions associated with message-to-buffer conversion and device 
control. In the PSAT, the MsgIn and MsgOut drivers control I/0 
only between the PSAT and hosts. However, in the PSAT 
Translator, this I/O mechanism has been extended to control both 
the host interface and the satellite interface. Thus two 
MsgIn/MsgOut driver pairs exist, one attached to the High Speed 


Modem (HSM) used for communication with the BSAT and another pair 
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attached to the Satellite Modem Interface (SMI) used for 


communication with the ESI-A,. 


As in the PSAT HPM, MsgIn and MsgOut provide message [1/0 
service to message level input and output processes, HstIn and 
HstOut. In the PSAT, HstIn and HstOut perform Host Access 
Protocol (HAP) message processing. In the PSAT Translator, HstIn 
and HstOut have been altered to perform the burst processing 
required to convert ESI-Betype bursts into ESI-A-type bursts. 
Since there are two pairs of device drivers, there are also two 
HstIn/HstOut pair analogues called XlatIn and XlatOut. To 
distinguish between pairs, the XlatIn/XlatoOut processes 
associated with the High Speed Modem are referred to as BSAT 
XlatIn and BSAT XlatOut. The processes associated with the 
Satellite Modem Interface are referred to as Satellite XlatIn and 
Satellite XlatOut. Communication between the BSAT XlatIn process 
and the Satellite XlatOut process is accomplished through a 
message queue. This queue is called UpQ, since it provides 
uplink communication between message level I/0 processes. 
Similarly, communication between the Satellite XlatIn process and 
the BSAT XlatOut process is accomplished through a queue called 


DnQ, so named for its downlink role. (See Figures 2 and 3) 
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In the PSAT Translator, the conversion of ESI-Betype bursts 
into ESI-A-etype bursts is performed in the Satellite and BSAT 
XlatIn processes. The XlatOut processes function only as message 


passers. 
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2.4 2 


are of the following format: 


PS 


All 


AT Translator Protocol 


packets passing between the BSAT and the PSAT Translator 


poeweemneene ee wee www ne== + 
} Xlator Control Word H 
$e eemwmmwoowooonn wwnnane + 
| TTG(1) | (not present in Data Packets) 
$a ewe mm mwm eww meme een wwe + 
| TTG(0) ! (not present in Data Packets) 
teen nocn ae wew eww mown wens + 
{| Pkt Type/Length Word |! 
pe ween wee eee eeemnnnne -<—+ 
| Data | 
+ é + 
H ‘ | 
+ ‘ + 
! | 
poe wewmewe reece emewoowaeee + 
13 
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a aS 
ae > 
t The PSAT Translator control word communicates various status x | 
ne and label information between the BSAT and PSAT Translator. The 

ast fields are defined as follows: 

2, = 
es Bit 0 (1sb): Last Packet of Burst ° 
ee Bit 1: Local Time Update Request one 
e Bit 2: Data Packet 7 ! 
a Bit 3-9: (Not currently used) a 
= Bit 10: Hard ESI Reset Request ne | 
eo Bit 11-13: (Not currently used) = 
S Bit 14-15: PSAT Translator Loop Status _ 
tat The ‘Last Packet of Burst' field indicates that the current 7 
aa packet is the final packet in the current burst. For the ESI-A, a * 
a burst may consist of one or more packets: a control packet < 
ou followed by one or more data packets. The PSAT Translator uses * 
ae this bit to signal completion of burst assembly to the Super Sue m4 
a Poller. When signalled, the Super Sue Poller will initiate DMA 7s 
oa transfer of all packets in the round-robin table through the 
es Satellite Modem Interface to the ESI-A. The 'Local Time Update & 
ae Request! field indicates that the PSAT Translator should return a Ss 
= local control packet of type ESI=-to-BSAT to the BSAT éohtaiai ng = 
me the current local time as maintained by the SMI. To maintain a 
ae accurate channel timing, the BSAT requires periodic updates of 
Pig local time. 5 
ee . 
Be = 
att 14 

: s 
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“a i] The 'Data Packet field indicates that the current packet is 
a oe a data packet as distinguished from an ESI-A control packet. 
The 'Hard ESI-A Reset Request! field indicates to the PSAT 

wat, 
ee oe that it should perform a hard reset of the ESI-A. A hard reset 
Redie consists of toggling a control wire in the SMI/ESI-A cable. 
{ ne The 'PSAT Translator Loop. State' indicates the current 
ae . Translator loop. status. Bit 14 indicates SMI loop and Bit 15 
ee Me indicates TR loop. Both bits clear indicates no loop. Both bits 
ee" 

ee set indicates PSAT Translator Software loop. 
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3 TACTICAL PACKET SATELLITE NETWORK me 


The Mobile Access Terminal Network (MATNET) will hereafter me 
be designated as the Tactical Packet Satellite Network (TACNET). 
After renewal of the contract for our participation in further es 
TACNET development, we conducted a study of suitable 
architectures for the second-generation TACNET systen. In this 
Quarterly Technical Report, we provide preliminary results of our wo! 


architectural investigations, with emphasis on TACNET security 


issues, Se 

The new TACNET Satellite IMP (SIMP) will be implemented on ~ 
modular BBN Butterfly Multiprocessor hardware, The re 
multiprocessor modularity will provide the flexibility to handle “~. 


a variety of diverse system requirements, as well as_ the vee 


expandability required to provide increased throughput under 


heavier system traffic loads. The multiprocessor design will 3 ' 
allow a variety of hosts to be connected into the network and m : 
will allow for several types of radio channel equipment to be s : 
serviced simultaneously. Given that TACNET will be required to a 
carry classified data in an operational Navy environment, our ot 4 
design will provide the capability to include end-to-end network = a 
security devices, as well as separate satellite channel ‘ : 
encryption devices. . ) 
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S 3.1 The Butterfly Multiprocessor 
ae 
soe oe The Butterfly Multiprocessor was originally developed for 
me the Voice Funnel application in the DARPA Wideband Satellite 
= “! Network, In that capacity it acts as a high performance Internet 
os ~ Gateway for the routing of speech traffic using the ST Internet 
y oe packet speech protocol. It also aggregates small speech and 
cee i video packets into larger packets for transmission on the 
= satellite channel by the Pluribus Satellite IMP (PSAT). At this 
eS time six 10-processor Voice Funnels have been built for the 
a 7 Wideband Network. A Butterfly-based version of the Internet 
os : Gateway is under development for the DARPA Internet project. 
hag ) Initial deployment of these gateways will begin in early 1985. A 
Ane : new Satellite IMP, the BSAT, based oon the Butterfly 
Par ey 
ot 5 Multiprocessor, is currently under development for the Wideband 
. e Network, The software to be developed for the new TACNET 
a ae Satellite IMP will draw heavily on our experience in developing 
es : the BSAT. 
2. ae The Butterfly Multiprocessor consists of processor nodes 
os = interconnected by a switch whose paths are patterned after the 
oe “ Fast Fourier Transform "Butterfly" network. Each processor node 
ee. x includes a Motorola MC68000 microprocessor with a bit-esliced 
= ay microprogrammed coprocessor, up to 4 Mbytes of local memory, a 
om re memory management unit, optional high-speed intelligent chained- 
3 DMA I/O channels, and an interface to the Butterfly switch. The 
RE 
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system is expandable by adding more processor and switch nodes 


(described below). 


The current Butterfly switch is built up from radix-4 switch 


nodes, It contains Y-bit-ewide data paths and runs at a clock 
rate of 8 Mhz to achieve a 32 Mb/s throughput. All memory in the 
system is global in the sense that it is directly accessible by 


each of the processor nodes via the switch. 


Each I/0 device in the system is associated with a single 
processor node. Several specialized communications-oriented I/0 
devices either have been designed or are in the process of being 
designed for the Butterfly. These include a synchronous (four 
channels) and asynchronous (four channels) serial I/O board, an 
interface to the satellite channel equipment for the Wideband 
Network, and an interface to a Ti ecircuit-switched telephone 
network. In addition, we have developed a Multibus adaptor which 
will allow a wide variety of standard Multibus compatible I/0 


devices to be connected to a Butterfly processor node. 


An operating system, Chrysalis, has been developed for the 
Butterfly to handle real-time communications tasks in the 
multiprocessor environment. Chrysalis supports the execution of 
independent user-level processes written in the C programming 


language. Chrysalis provides virtual and physical address space 
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" 

n] interprocess communication, synchronization, and task 

3s as distribution mechanisms ("events" and "dual queues"), and system 
cS a timers, Chrysalis itself is written in C with many of its : 
pee . underlying mechanisms implemented on the microcoded coprocessor 


rt. for significant performance enhancement. 


Detailed documentation of the Butterfly Multiprocessor and 


{ 

Ree the Chrysalis operating system can be found in the series of BBN : 
oe Quarterly Technical Reports provided to DARPA for The Voice : 
Ae ~ 

: a Funnel project. 

aa 

os 

re) 

ae ." 

eae 3.2 Overview of TACNET Security Issues 


, 


. ; It has been recognized for some time that the imposition of 

im z network security devices into the current C/30-based system has : 
= ] severely handicapped the system integration. In addition, the 

ra m nature of the security devices has interfered with the use of the 

wt TACNET system in many of the Navy's demonstration and testbed 

° - environments. We realize that for any packet-switched satellite 

s “ communication system to gain acceptance and be used in a Naval 

a operational environment, the issue of network security must be 
eo addressed and solved. It must be included and dealt with 

: a throughout the system design and development phases and not just 

“ tacked on shortly before declaring the system operational. It is ; 
eo. for this reason that our preliminary investigations have resulted j 
~ 
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in an evolutionary system that will first integrate packet 
satellite technol ogy into the Navy's shipboard and shore-based 
environments with appropriate security measures for the testbed 
environment, and will later replace these initial security 
devices with more sophisticated security devices as the 


requirements of the operational mission are defined. 


The initial version of the new TACNET system will be used in 
the testbed environment. It will not carry any sensitive data 
and will not inelude any security devices. This system will be 
used for the development of interfaces for the various radios 
that are contemplated for use by TACNET, for the development of 
appropriate codecs and interleavers for noise immunity, and for 


continued work on the PODA algorithms. 


The TACNET Satellite IMP will inelude support for HDLC 
physical host interfaces. Such interfaces are compatible with 
the currently planned family of packet-switched network end-to- 
end security devices. In the testbed demonstration environment, 
it may be necessary to protect unclassified sensitive data. We 
would use a DES=-based security device in the host-to-SIMP link to 


provide protection of such data, and explore the impact of end- 


to-end security devices on the operation of the network. 


, As the classification of the data carried by TACNET 


increased to the SECRET level, we would exchange the DES-based 
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devices for Internet Private Line Interfaces (IPLIs). The IPLIs 
will support the same host protocol as the DES devices and will 
be interchangeable. The introduction of SECRET data into the 
network and the IPLI in particular will require an increase in 
the network's physical security (red-black engineered 


environment, TEMPEST, etc.). 


In anticipation of having TACNET carry still higher level 
classified data in an operational system, we propose to design 
the system with the capability of introducing some form of 
encryption on the satellite channel at a future time. In 
particular, we propose a separation of the satellite channel 
protocol functions from the satellite link transmission/reception 
functions, the different sets of functions being perforrea in 
separate Butterfly processor nodes. When encryption is required 
on the satellite channel, we will interpose a DES-based security 
device between the two subsystems. This will allow us to cover 
the addressing portions of the messages on the satellite channel 
in order to guard against traffic analysis. The Butterfly 
processor(s) on the satellite channel side of the security device 
will only be executing software controlling the codec/interleaver 
and the radio(s). The processor node(s) on the other side of the 
security device will run the satellite channel protocol module 


(i.e., will perform the scheduling of the satellite channel). 
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The architecture of the DES-based security device as 
described below will allow for a much more sophisticated 
cryptographic bypass than is provided in the current C/30-based 
systen, In a real operational system handling data that is 
classified as TOP SECRET and above, we anticipate replacing the 
DES-based device in the satellite channel path with one of the 
encryption devices from the Blacker program (with software 


modifications for the TACNET application). 


3.3 Detailed Examination of Two of the Proposed Systems 


In this section, we will discuss two important stages in our 
evolutionary plan: one in which only end-to-end encryption on the 
host links is used, and one in which some type of encryption 
(with an appropriate bypass) is used to protect addressing 
information on the satellite channel itself in order to guard 


against traffic analysis. 


In both of the architectures to be described, the need to 
protect the DATA content of classified traffic or sensitive 
unclassified traffic can be satisfied by the use of encryption 
devices external to the TACNET system. IPLIs can be used in the 
Classified case, and DES=-based devices can be used in the. latter 
privacy-only case. Both of these devices can be used for end- 


to-end encryption across many interconnected networks, so that 


22 


a a a ee . -" -* - * 8 
th ol Pat . Ore) ova rs afat. atte 


eo 
aa 


4, G *s ‘, 


ry 


aad FE EPO XP td 


yn or a a oo eS wy 


att aa 


‘ ‘e a! 


: 


Report No. 5580 Bolt Beranek and Newman Inc. 


they will not necessarily be directly connected to TACNET host 
ports. If an IPLI or DES-based device is connected to a TACNET 
host port, the encryption device will interface to the network in 
the same fashion as any other external host. Since the provision 
of message DATA content protection is a standard use for which 
the security devices are being developed, there may be little or 
no NSA involvement required when they are sc used by the TACNET 


application. 


3.3.1 System A 


This new TACNET architecture does not address the traffic 
analysis protection requirement: It is assumed in this case that 
the system will never be expected to handle (cipher-text OR 
plain-text ) messages whose addressing information must be 
concealed. The most significant aspect of System A is that it 
contains no internal encryption devices, permitting a system 
architecture which is much simpler than that used in the current 
C/30-based system and requiring no NSA approval of any of the 
TACNET components. In such an "all black® system, the processing 
components performing the satellite channel scheduling have easy 
access to all of the known information on the state of the 
channel, . since their communi cations with the codec/interleaver 


and AN/WSC-3 radio interfaces are unencumbered by encryption 
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devices or limited-bandwidth bypasses. This permits complete 
channel-state reporting to the network monitoring site, and may 
also simplify the implementation of any solutions to the 
contention packet discrimination problen. Additionally, no 
communications bandwidth is lost within the TACNET system because 
of encryption overhead (per-packet initialization vectors, fill, 


etc.) to possible encryption device alarms. 


A block diagram of System A is shown in Figure 4. The 


complete host message routing, satellite channel protocol, and 


Satellite IMP monitor/control functions, as well as the higher 
level parts of the host interfacing, codec/interleaver control, 
and AN/WSC=-3 control functions will be implemented as C-language 
software which will be compiled for execution on the MC68000 


processors resident on the Butterfly processor nodes. 


HDLC link-level host interfaces will be provided, Although 
the current Butterfly I/0 board provides HDLC ports, it may be 
most flexible (given the various system I/O requirements) to use 
Multibus-compatible I/0 boards. These host interface boards each 
contain an HDLC and an 1822 port driven by a microcodable 
processor, The on-board processor could be microcoded to 
interact with the Chrysalis operating system so as to eliminate 


the lowelevel host-I/0 processing burden that would otherwise be 
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t | placed on the MC68000 application software, : 
ma? 
ae 
pea The use of Multibus-compatible boards by a Butterfly = 
ae! oe 
=" processor node requires a Multibus adaptor board to perform the 

Ld 
ae conversion between the standard Butterfly I/0 bus (the BIOLINK) - 
j ee 
Ne and the Mul tibus. Such a board has been developed for é 
we, pee 
c a Butterfly-based Internet Gateway. a 
we 

ee The encoding/decoding and interleaving/deinterleaving 
ee functions will be provided by another Multibus-compatible device. oa 
a BBN will evaluate commercially available codecs and interleavers . 
a to determine if they are suitable and available with the ic 
e SN). _ 
ae appropriate level of vendor support for the TACNET system. If no 2. 
Maar) suitable commercially available codecs and interleavers are - 
“~ 
aan found, BBN will undertake to develop an appropriate codec and nae 
oo ; . 
ot interleaver. 

) # 
a The AN/WSC-3 interface would also be located on the - 
ae Multibus. Its functions would include transmitter keying, modem S 
rs preamble generation, unique word correlation, maintenance of the 
aoe x 
ste local transmit/receive clock, etc. A key criterion for the “ 
oer selection or design of the codec/interleaver and AN/WSC-3 a, 
an a 
e interfaces will be their ability to provide intelligent DMA-based = 
a0 interfaces to Butterfly processor nodes to reduce the processing a 
el a 
eae burden on the MC68000 device driver software. 
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3.3.2 System B 


Changes must be made to the System A architecture if TACNET 
will be required to handle messages whose addressing information 
must be encrypted before being broadcast over the satellite 
channel. The resulting architecture (such as "System 8B", 
described below) requires some form of encryption device(s) to be 
placed within each TACNET Satellite IMP. The exact form of 
encryption device used depends on, among other factors, whether 
the addressing information is categorized as classified or 
unclassified (but sensitive). In the former case, a high-grade 
COMSEC device would be used for address encryption; in the latter 
case a privacy-only device using DES may suffice. Some form of 
NSA approval would be required in either of these cases, although 
the standards used for the approval would be different for the 
two general device types, The placement of any encryption 
devices within TACNET adds some complexity to the system and may 
affect system throughput in much the same way as it does in the 
current C/30=-based system, i.e., the system divides into a "red* 
and a "black*® subsystem, the processors in the two subsystems 
communicating through the encryption device (whose operational 
mode may add to the system overhead) and a limited-bandwidth 


by pass. 


It must be stressed that the degree of difficulty inherent 


in providing address information enoryption within TACNET (due to 
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obtaining/developing NSA approved devices and due to encryption 
device bypass constraints) is strongly affected by the type of 
device used, and hence by the classification of the addressing 
information. (In those cases where a DES-based device is 
allowable the difficulty is minimized, resulting in a system that 
is simpler and more flexible than the current C/30 system. Such 
a DES-based architecture is represented by System 8B, which is 
described below.) If the new TACNET system will be considered to 
have an operational role in Naval communications, and in this 
role will process messages whose addressing information must be 
treated as classified independent of the message data content, 
then the relatively complex route of using a high-grade COMSEC 
device must be taken. On the other hand, if the new TACNET 
system's role is solely one of demonstration of concept, and as 
such the address information is unclassified, then the simpler 
DES-oriented privacy-only route or the even simpler "all black*® 


system route (System A) would suffice. 


A block diagram of System B is shown in Figure 5. Sy stem 
B's "red"® side contains the same Butterfly processor nodes and 
host interfaces as System A, The "black" side of System B 
consists of Butterfly processors which are connected to the 
codec/interleaver and AN/WSC=-3 interface devi cea The red 


subsy sten performs all required functions other than 
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ecodec/interleaver and AN/WSC-3 control; the latter are handled by 


the black subsystem, 


The red and black processor nodes communicate using DES- 
based security hardware which will be connected to the nodes via 
HDLC interfaces. The security hardware will be contained in a 
separate box and will be identical to that being developed for 
other applications by BBN. Modifications will be made to the C- 
language software which executes on the MC68000 that is contained 
within the security device. Such modifications are required 
because of differences between the TACNET application and other 
applications using the DES-based device (which generally have the 
security device located between a host and its packet-switch 
node). The security device's software would be set up “to pass 
control and status messages between the red and black processor 
nodes without performing any encryption or decryption operations 
on such messages, thereby providing a high-bandwidth bypass. The 
software will also bypass certain control data prepended to 
packets to be broadeast over or received from the satellite 
channel, e.g., packet transmission/reception timestamps. Such 
bypass capability provides a far simpler and much more flexible 
red/black subsystem interface than that contained in the C/30- 


based systen. 


Separately packaged DES hardware is used in System 8B _ to 


expedite the required NSA approval for its use in the TACNET 
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application as a privacy device under Federal Standard 1027. 
Since 1027 approval is anticipated for some of the other DES 
device applications, and since the TACNET software modifications 
are expected to be minimal, approval should not be difficult. 
The alternative route of using a DES board as a peripheral device 
directly accessible by a Butterfly processor node is not being 


taken, since it would probably require 1027 approval for _ the 
entire Butterfly system. 
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